The present invention relates to the fields of distributed computing systems, client-server computing and object-oriented programming. More specifically, the present invention teaches methods, apparatus, and data structures for managing computer processes.
Object oriented programming methodologies have received increasing attention over the past several years in response to the growing tendency for software developed using traditional programming methods to be delivered late and over budget. This stems from the fact that traditional programming techniques which emphasize procedural models and xe2x80x9clinearxe2x80x9d code tend to be difficult to design and maintain in many circumstances. Generally, large programs created using traditional methods are xe2x80x9cbrittlexe2x80x9d, That is, even small changes can effect numerous elements of the programming code. Thus, minor changes made to the software in response to user demands can require major redesign and rewriting of the entire program.
Object oriented programming strategies tend to avoid these problems because object methodologies focus on manipulating data rather than procedures; thus providing the programmer with a more intuitive approach to modeling real world problems. In addition objects encapsulate related data and procedures so as to hide that information from the remainder of the program by allowing access to the data and procedures only through the object""s interface. Hence changes to the data and or procedures of the object are relatively isolated from the remainder of the program. This provides code that is more easily maintained as compared to code written using traditional methods, as changes to an object""s code do not affect the code in the other objects. In addition, the inherent modular nature of objects allows individual objects to be reused in different programs. Thus, programmers can develop libraries of xe2x80x9ctried and truexe2x80x9d objects that can be used over and over again in different applications. This increases software reliability while decreasing development time, as reliable programming code may be used repeatedly.
A more recent advance in the field of object oriented methodologies has been the implementation of distributed object operating environments over computers interconnected via a computer network. As used herein, the term xe2x80x9cdistributed objectxe2x80x9d or xe2x80x9cobjectxe2x80x9d refers to an encapsulated package of code and data that can be manipulated by operations through an interface. Thus, distributed objects will be seen by those skilled in the art of object oriented programming (OOP) as including the basic properties that define traditional programming objects. However, distributed objects differ from traditional programming objects by the inclusion of two important features. First, distributed objects are multilingual. That is, the interfaces of distributed objects are defined using an interface definition language that can be mapped to a variety of different programming languages. One such interface definition language is IDL. Second, distributed objects are location-independent, i.e., distributed objects can be located anywhere in a network. This contrasts sharply with traditional programming objects which typically exist in a single address space.
Distributed objects can be object clients or object servers, depending upon whether they are sending requests to other objects or replying to requests from clients. In a distributed object environment, requests and replies are made through an Object Request Broker (ORB) that is aware of the locations and status of the objects. One architecture which is suitable for implementing such an ORB is provided by the Common Object Request Broker Architecture (CORBA) specification. The CORBA specification was developed by the Object Management Group (OMG) to define the distributed computing environment world in terms of objects in a distributed client-server environment, where server objects are capable of providing services to clients requesting the service. In the following discussion, the terms xe2x80x9cobjectxe2x80x9d and xe2x80x9cdistributed objectxe2x80x9d will be used interchangeably.
When a client calls a target object, certain procedures must be performed to ensure that the target object can perform the requested service(s). These procedures include identifying and locating the target object, starting the server process (if necessary) under which the target object resides, activating the target object if necessary, and, finally, establishing a connection with the target object and passing the call. The ORB would be ideal for managing server processes at all stages, including starting and registering the server processes. What is needed is a framework for managing server processes under a distributed object operating environment.
To achieve the foregoing and other objectives and in accordance with the purpose of the present invention, methods, apparatus and data structures for managing computer processes are taught. According to one aspect of the invention a daemon process running on a host computer system in a distributed object operating environment includes an active server table and a locator service. The active server table has a data structure for maintaining entries related to a multiplicity of server processes that are currently running on the host computer. These entries include a server identifier, a server process state, and server process addressing information. The locator service accesses the active server table to provide addressing information about the server processes to a client requesting this information. Furthermore, the locator service registers server processes into the active server table.
In one embodiment, the daemon process also has an object adapter database resident therein. In additional embodiments, the object adapter database is resident elsewhere in the distributed object operating environment. One specific embodiment has the object adapter database in a separate process running on the host computer. The object adapter database includes data elements such as target object identifiers, server identifiers each corresponding to at least one target object identifier, and object references, each object reference corresponding to a target object identifier. In further embodiments, the locator service includes two objects, a locator object and a server process registration object. The locator object performs the server look-up function, and the server process registration object performs the server process registration function. A still further embodiment is contemplated wherein a distributed object operating environment includes a multiplicity of computer systems connected by a network with a distinct daemon process as described above running on each one of the computer systems.
In a separate aspect of the present invention, a computer system for use in a distributed object operating environment is contemplated. The computer system includes a central processing unit, memory accessed by the central processing unit, and a locator service implemented on the computer system. A plurality of distributed objects reside in the memory. The locator service manages the distributed objects and any server processes executing on the computer system. In several related embodiments, the computer system will have means for performing the method aspects of the invention as described below.
In other aspects of the invention various methods for managing server processes such as starting and registering server processes are disclosed. These server processes reside on a server host computer. In a first method, a daemon process resident on the server host computer performs the steps of receiving a look-up call for a target object, obtaining a server identifier for said target object, determining a state of a server process, and returning addressing information corresponding to said server process. The server process is uniquely defined within the server host computer by way of the server identifier. In one method aspect, the server process state is determined to be running and, as a result, the step of returning said addressing information is performed immediately. In another method aspect, the state is determined to be starting and, as a result, the daemon process waits until the state transitions from starting to running before returning the addressing information.
In another method aspect, the step of obtaining a server identifier for the target object is performed by accessing a first database. By way of example, the first database may be an object adapter database. Furthermore, the state of the server process is determined by looking it up in a second database. In one example, the second database may be an active server table. In another embodiment, the first and the second databases are the same database.
In a still further method aspect, when the state of the process is determined to be not active (i.e. the server process is not found in the second database), the daemon process creates a server process entry in the second database. This entry includes a server identifier and a server process state. The daemon process then continues by marking the server process state as starting, accessing the first database to get an execdef for the target object, starting the server process using the execdef, and waiting until the server process state transitions from starting to running before returning the server process addressing information to the client. By way of example, the execdef may be the server""s program name and any necessary arguments.
In yet another method aspect, the server process responds to being started by obtaining a server process identification number from the operating system of the host computer. Then it creates a communications port for the server process, forms addressing information for the server process, and then calls a server process registration object resident in the daemon process. The operation of this call will invoke a register server operation. As arguments to this call, the server process passes the addressing information, the server process identification number, and the server identifier. In response to this call, the server process registration object stores the addressing information in the second database and marks the server process state entry as running.
In another separate aspect of the invention, a self-start method for a server process (i.e. self-start and register) is taught. The method begins when the server process receives a request to become a server along with an object reference for the desired target object. In response the server process begins executing and obtains a server process identification number from the operating system of the host computer. Next it performs the steps of creating a communications port for the server process, forming addressing information for the server process, obtaining an object reference for a server process registration object from an object request broker object file and calling the server process registration object to invoke a register new server operation. Then, in response to this call, the server process receives a server identifier corresponding to itself.